1. Field of the Invention
The present invention relates to a method for providing secure registration and integrity assessment of software in a computer system.
2. Description of the Related Art
The field of computer security, encompassing both computer protection and integrity assessment, is becoming increasingly important given the ever-expanding role computers play in today's society. Huge amounts of money are invested by companies and individuals to purchase executable software. Even more money and time is spent developing the information contained in data files such as text documents and spreadsheets. Protecting these resources is therefore an important concern. Security-conscious users are requesting that security and integrity features be incorporated into their personal computers to restrict access to critical files and to guarantee the trustworthiness of installed programs.
One prior method of offering protected access to files involves the use of passwords. A password is typically stored in battery-backed CMOS memory. Before the user is allowed access to the computer, the user is required to enter a password. Once entered, the computer compares the entered password to the password in CMOS and, if they match, the user is allowed access. The main disadvantage with this scheme, as discussed more fully below, is that passwords offer very little protection against certain forms of data corruption. Second, other forms of attack can bypass the CMOS memory because it is not read-protected in many cases. To address this concern, passwords are sometimes encoded. Once the encoding scheme is reverse-engineered, however, security is easily breached. Further, the CMOS memory could simply be disconnected from its battery, thus losing any contents including the password.
A related art to that of computer protection is integrity assessment. Integrity assessment is used herein to denote methods used to ascertain the trustworthiness of data or software code. Software is assumed to be trustworthy when initially installed, and the system is in its most reliable state immediately following a proper installation. System software that has been changed, whether through an unauthorzed deliberate act or through an accidental system malfunction, is said to have undergone an "integrity violation". In such cases, the software is presumed to be untrustworthy and capable of violating the integrity of other parts of the computer system. It should be noted that in this context, integrity and trustworthiness have little to do with defects in the design of the software, or bugs in the in the software, although certain bugs could cause the integrity of the software to be jeopardized.
"Trusted software" is normally defined to be a subset of all software used by a computer system, the subset being responsible for the correct and reliable operation of the system. Trusted software is also responsible for enforcing a system's security policy. Maintaining the integrity of trusted software is therefore particularly important.
The two main causes of software untrustworthiness are file corruption and viruses. File corruption usually follows a system failure occurring during a file transfer (i.e. the system is turned off while a file is being copied onto the hard disk etc.). Another--and much greater--threat to software integrity is the problem of malicious software code (also referred to as "computer viruses").
While many computer viruses are relatively benign, computer viruses can be hostile, clandestine and created to target specific types of software or hardware. They can be introduced into a computer in as many ways as the computer can communicate externally, such as through the floppy drive, a network connection or a modem connection. Viruses are typically designed to replicate by secretly attaching copies of themselves to files or boot records so that the user is unaware of the intrusion. It is important to note that once a virus has attached itself to a host program, the file must be different and its integrity has been violated.
Once infected, any subsequent copies of the host file also contain the virus, thereby increasing the potential for destruction. The virus is then activated when the file is executed. Consequently, a virus attached to a data file may remain dormant because the data file is not executable.
One common commercial method of assessing the integrity of user software is to check for viruses by running a virus checking software program. Such programs rely on the characteristics of the known viruses to detect their presence. A new virus may not be detectable by the virus checking software. Additionally, if a virus is present, the virus checking software itself is susceptible because it is loaded from the infected hard disk and must run in memory that could be infected.
Another method of assessing a file's integrity prior to executing involves computing an integrity assessment code for the file and verifying that the code matches a predetermined value. Checksums (a type of integrity assessment code) are adequate for detecting accidental modifications of data. However, they are an insecure defense against viruses. A well-designed virus aimed at bypassing normal security features can easily attach itself to a host program without resulting in a different checksum.
To address this problem, advanced modification detection codes (MDCs) have been developed to specifically detect deliberate corruption of data, and are superior to simple checksums. It is intended to be computationally infeasible to modify data so as to preserve a specific modification detection code value. Modification detection codes are sometimes referred to by other names, including: "cryptographic checksums", "cryptographic hashes", "secure hash algorithms", and "message digests". The term "secure hash value" or "hash value" is used throughout the remainder of this specification to refer generally to a value generated by a modification detection code, the value being specific to a given software application. Modification of the software results in a different hash value.
In some earlier systems, a secure hash value is calculated and stored for newly installed software. Thereafter, when the computer is turned on again, the stored hash value is compared to a newly calculated value. If a discrepancy is found, the user is alerted. A main disadvantage with this method is that the integrity assessment codes must be stored on the hard disk, thus making the codes themselves susceptible to attack by malicious code. Reverse-engineering a modification detection code, while difficult, is not a mathematically intractable problem. Thus, software-only protective products can offer only limited insurance against the attack of malicious code, due mainly to architectural weakness present in most computer systems. A potential solution is to embed the modification detection code in a permanent read-only memory device, but this can make system reconfiguration quite difficult.
A more secure technique is described in U.S. patent application Ser. No. 5,421,006, filed Apr. 20, 1994, entitled "METHOD AND APPARATUS FOR ASSESSING INTEGRITY OF COMPUTER SOFTWARE", which is hereby incorporated by reference. The described technique uses CMOS memory as a non-volatile memory (NVRAM). The NVRAM has one location which can be write-protected by a write once bit. Once set, the write protection cannot be removed until the computer is reset. This location holds secure hash values for certain operating system programs located on the hard disk. Software in the ROM BIOS needs the protected operating system programs and the hash values of those programs. If the calculated hash value matches that stored in the NVRAM, then the programs are secure and can be executed.
In one embodiment; the write protection is activated at this time. In an alternative embodiment the write protection is activated later, before the first non-checked program is executed. The operating system is then loaded and boots the computer. The operating system can then check each additional file before it is executed. Checking consists of calculating the hash value of a program, comparing it to a value in a previously checked table, and passing the program if there is a favorable comparison. If the hash value of the program does not match that stored in protected memory, the program has changed and may include a virus.
While the technique is very secure and usable in an ideal environment, a PC is far from an ideal environment. Files change often, causing bookkeeping problems due to the need to update MDCs. Further, many PC's have very complicated booting procedures that can be interfered with by the technique.
An improvement upon the aforementioned technique has been described in commonly-owned U.S. Pat. No. 5,537,540, entitled "TRANSPARENT, SECURE COMPUTER VIRUS DETECTION METHOD AND APPARATUS", and hereby incorporated by reference. This invention (hereinafter referred to as the "SAFESTART patent") reduces the administrative requirements of the earlier technique. A reserved non-DOS hard disk partition is used to pre-boot the computer system and provide a secure environment from which to verify files. Upon power-up or reset, the computer performs the power-on-self-test, during which it checks a SAFESTART track by comparing its hash value to value stored in NVRAM. If the integrity of the SAFESTART track is verified, the first "SAFESTART" routine is loaded into memory and executed.
The SAFESTART routine first checks the master boot record and boot sectors of the hard disk. This verification captures a large majority of viruses and is performed before any code residing in those areas is executed, thus preventing the spread of any discovered viruses. Further checks are performed on SAFESTART files before each is executed. Eventually, system files and any additional designated user files are verified. Since the computer system booted from an atypical partition, the drives are remapped to account for the shift in logical disk drive addressing. When the verification process is completed, SAFESTART files are cleaned up, a latch is set to prevent unauthorized modification of the initial hash values, and control is returned to the BIOS to boot the user operating system.
The reserved non-DOS partition contains three different sets of DOS: a copy of the User DOS (if DOS is installed on the user partition), a subset of system DOS called SDOS, and a backup of the DOS subset. According to the patent, the reserved non-DOS partition is bootable by SAFESTART. During SAFESTART, the default operating system is the User DOS, if installed. Otherwise, SDOS is used as the pre-boot operating system. If one of the operating systems becomes infected, an unaffected copy of DOS is dynamically restored. Thus, a computer system implemented according to the SAFESTART patent insures that designated software is trustworthy following a power-up cycle.
At a certain point after startup, the set of trusted software may become vulnerable to attack, and can no longer be relied upon to perform trusted operations. In order to revalidate the trusted software or reconfigure the integrity assessment software, prior protection schemes such as those disclosed in the SAFESTART patent require that the system be restarted. This interruption is often time-consuming and may present an unwelcome break in computing activities.